Since the automation of business operations, data managers have worried about how to recover from a loss of data, be it from computer malfunction, natural disaster, or human error. Typically, businesses make image copies of the current state of their data on tape and send the tapes to an off-site location for storage in the event of a disaster at the on-site location. In the event of a total disaster, the business can easily restart their operations with the data in the state it was when the last off-site backup was made. This approach suffers from several drawbacks. Transactions occurring after the backup copies are made are lost and have to be recovered by some method other than via the off-site backups. For some businesses, this reentry would just add to the nightmare of the disaster. For example, a bank's automatic teller users or an airline's agents would have to reenter days or weeks worth of on-line activity. Full image backups of this type should be made as frequently as possible to minimize the number of transactions that would have to be reentered. At a typical computer site, backup could be done as often as once a day if there is a period during the day in which little or no activity is taking place. Minimal activity periods are needed for this scheme, since, in many installations, no transactions can be entered while the data is being backed up. Having to stop computer operations presents a problem to sites that are working 24 hours per day. Often, the value of computer equipment is measured by the number of hours per day that it can be actively operating, so increasing downtime and resource usage for backups decreases the value of the equipment. One solution to this problem is that the computer system make instantaneous backups. As each transaction is created and written to disk, it is also written to tape. While this does keep information more up to date and doesn't require any downtime, the disadvantage of this approach is that the perceived response time of the computer is increased to unacceptable levels since the processor must now do twice as much writing to computer peripherals. This instantaneous information, commonly called log or journal data, can be used in combination with the backups and a utility generally provided by the DBMS vendor which would reconstruct the current data from the backups and the log information which shows each successive change to the database. For this to be done reliably requires that every single record of a change to the database be known since changes later in time are directly dependent on changes that were done earlier in time. If earlier changes are not recorded, later changes will have a tendency to corrupt the data. Generally in a recovery process, a data administrator would not use any record of changes that occurred after the point where information about the changes had been lost. This is a case where having no data is actually preferable to having some incomplete data. There is currently no easy way, aside from making complete image backups of the databases, to insure that the journal of database changes which has been moved off-site is actually a complete set of all changes made to the database. Without this assurance, a prudent data administrator would abandon the entire change log back to the last complete image backup. The present invention solves each of these shortcomings of the prior art.
One embodiment of the present invention is known as E-NET1 Release 2.0. An earlier version, Release 1.1 of E-NET1 which is prior art to the present invention, solved some of the problems associated with data recovery, but failed to solve most of the problems that other prior art also failed to solve. E-NET1 Release 1.1 could not handle abnormal terminations of the operating system at the sending site, nor the abnormal termination of E-NET1 Release 1.1. Any gaps in the data that were created in such situations remained as gaps in the data. No capability existed within Release 1.1 to recover a loss of data, and users were required to restore the lost data manually. While E-NET1 Release 1.1 could move log data from a central site to a remote site via electronic communication lines, it required the communication lines to be operating and throughput to be high enough so that the sending queue at the central site did not overflow, since queue overflow in Release 1.1 resulted in lost data. E-NET1 Release 2.0 is referred to hereafter for brevity as E-NET1.